-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow dropping dyn
trait object's principal
#114679
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
r=me after you answer my question and add some (run-pass) tests 😁 It might make sense to still stabilize this with trait upcasting because unlike Does the current impl simply transmute the trait vtable to the empty auto trait vtable? |
Yes, it does -- it just reinterprets the vtable as being its common prefix. There's no new vtable being produced. |
@rustbot author |
018e98c
to
abbdc26
Compare
@@ -154,7 +154,9 @@ pub fn unsized_info<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>( | |||
) if src_dyn_kind == target_dyn_kind => { | |||
let old_info = | |||
old_info.expect("unsized_info: missing old info for trait upcasting coercion"); | |||
if data_a.principal_def_id() == data_b.principal_def_id() { | |||
if data_a.principal_def_id() == data_b.principal_def_id() | |||
|| data_b.principal().is_none() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bjorn3: if this PR ends up being accepted, the change will need to be made to cg-clif as well. should I do that in this PR, or in a separate one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing it in the same PR would be nice I think. You can change
rust/compiler/rustc_codegen_cranelift/src/unsize.rs
Lines 34 to 37 in a32978a
if data_a.principal_def_id() == data_b.principal_def_id() { | |
// A NOP cast that doesn't actually change anything, should be allowed even with invalid vtables. | |
return old_info; | |
} |
Discussed in T-lang triage meeting; our conclusion was that if immediate stabilization is desired, then @rust-lang/types is the right team to own authoring a stabilization report (or, if the effort for a stabilization report is unwarranted, then the PR author can instead add a feature gate), so this can remain S-waiting-on-team, but the relevant team is now T-types. @rustbot label: +T-types +I-types-nominated |
discussed in the t-types meeting: waiting on stabilization report + FCP by @compiler-errors |
I actually don't see any case where someone would want this. It's cute from the type system perspective, but I don't have the time to convince T-lang that this has a real world use case. |
… r=compiler-errors Allow dropping dyn principal Revival of rust-lang#126660, which was a revival of rust-lang#114679. Fixes rust-lang#126313. Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`. cc `@compiler-errors` `@Jules-Bertholet` r? `@lcnr`
Rollup merge of rust-lang#131857 - WaffleLapkin:dyn-drop-principal-3, r=compiler-errors Allow dropping dyn principal Revival of rust-lang#126660, which was a revival of rust-lang#114679. Fixes rust-lang#126313. Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`. cc `@compiler-errors` `@Jules-Bertholet` r? `@lcnr`
Allows us to cast from
dyn Trait + Send
todyn Send
, dropping the trait object's principal trait. This is distinct from trait upcasting, since it's trivial even if we were to totally rip out upcasting support -- it uses the same codepath as dropping auto traits, likedyn Trait + Send
todyn Trait
, which is currently allowed without feature gates on stable.This seems like something that would be nice to have, if anything, just for consistency. Nominating for T-lang discussion and FCP for that reason. I don't personally think this needs a feature gate, but that is also I guess up for debate!
This was originally noticed by lcnr in #113393 (comment).
r? types on the impl